[{"name":"No unsafe-inline","slug":"no-unsafe-inline","version":"1.2.1","author":"Giuseppe Foti","author_profile":"https://profiles.wordpress.org/mociofiletto/","requires":"5.2","tested":"6.5.5","requires_php":"7.4","requires_plugins":[],"rating":100,"ratings":{"1":0,"2":0,"3":0,"4":0,"5":4},"num_ratings":4,"support_threads":4,"support_threads_resolved":0,"downloaded":5800,"last_updated":"2024-05-08 6:28am GMT","added":"2022-03-25","homepage":"https://github.com/MocioF/No-unsafe-inline","sections":{"description":"

Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.
\nCross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications.
\nXSS attacks enable attackers to inject client-side scripts into web pages viewed by other users.
\nA cross-site scripting vulnerability may be used by attackers to bypass access controls like the same-origin policy.
\nLooking at National Vulnerability Database run by US NIST, more than 900 (March 2024) vulnerabilities are reported as XSS for WordPress’ plugins and themes.

Keeping your site up-to-date with the latest versions of plugins and themes is the first line of defense to ensure your site’s security.

The second thing to do, is to deploy a strict Content Security Policy.

The main problem

The main problem with Content Security Policies implemented in the real world is that they are too weak to really protect your site and that many of them can be trivially bypassed by an attacker.

The proposed solution

Google researchers recommend, instead of whole host whitelisting, to activate individual scripts via a CSP nonces approach.
\nIn addition, in order to faciliatate the adoption of nonce-based CSP, they proposed the ’strict-dynamic’ keyword.

The problem(s) with CSP in WordPress

\n
Manual creation of a policy
\n
Usually, a WordPress project is a mix of code written by different authors who contributed to the Core and or wrote plugins and themes.
\nIf it is possible to whitelist every external script loaded from a <script src=\"\">, the real truth is that in a WordPress project you can have dozens of those scripts included with your plugins and calculate a cryptographic hash for each of them to be included in your CSP header can be a frustrating job. However, there are many browser extensions and WordPress’ plugins that can help you in this job.
\n
\n
Inline scripts
\n
WordPress core, and plugins use inline scripts. For these scripts, you can compute hashes to be inserted manually into your policy, only if these scripts do not change at any page load. Unfortunately, this is not very common as it is frequent to include variable values calculated server side in inline scripts. And it means that your inline scripts change too frequently to manually add their hashes to your policy.
\nThis commonly happens when scripts are “localized”.
\n
\n
WordPress has no API to implement nonces for CSP
\n
Even if it is easy to generate a nonce for each page view, this nonce has to be inserted in every script tag used to embed inline scripts in your page as
\n
```
<script nonce=\"rAnd0m\">\n    doWhatever();\n</script>\n
```
\n
and in your script-src directive:
\n
```
script-src 'nonce-rAnd0m';\n
```
\n
And, of course, a nonce must be unique for each HTTP response.
\n
\n
Unsafe hashes / Inline styles
\n
Sometimes, HTML elements as images or button uses HTML Event Attributes (onclick, onsubmit…) to let events trigger actions in a browser.
\nYou cannot use hashes or nonces for script included in event attributes and, adopting a strict CSP, requires refactoring those patterns into safer alternatives or to use ‘unsafe-hashes’.
\nYou got a similar problem when inline styles are used in HTML tags:
\n
```
<h1 style=\"color:blue;text-align:center;\">This is a heading</h1>\n<p style=\"color:red;\">This is a paragraph.</p>\n
```
\n
CSP Level 2 browsers may be ok with just putting the hash in your style-src directive. However, to allow hashes in the style attribute on inline CSS on browsers that support CSP Level 3, you may get an error like this
\n
```
    Refused to apply inline style because it violates the following Content Security Policy directive: \"style-src 'self' 'sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='\". Either the 'unsafe-inline' keyword, a hash ('sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='), or a nonce ('nonce-...') is required to enable inline execution.\n
```
\n
To allow inline styles you need to use ‘unsafe-hashes’ in your style-src directive (that is, in facts, unsafe).
\n^
\n

This plugin approach

This plugin affords those problems in this way:

During a capture phase, it detects the scripts, styles and other embedded content present in the pages of your site and stores them in the database.
Then you have to whitelist these contents from plugin admin.
The plugin uses machine learning to cluster inline scripts trying to aggregate scripts generated by the same server side (PHP) code. So, you can authorize one script example to authorize all scripts that the classifier predicts to label as whitelisted clusters.
You can choose to use hashes to authorize external scripts (and the plugin will allow you to include Subresource Integrity in your <script> and <link>)
You can use hashes or nonces to authorize inline scripts.
You can ask the plugin to refactor your page to not use event attributes (converted in a inline script) and inline styles (converted in an internal CSS).
You can set one or more violations’ report endpoints.

The plugin supports multisite installations and has (too) many options documented in inline help.

Creating a Content Security Policy

After plugin activation, go to Settings menu and search for CSP Settings submenu.
\nThe steps you are supposed to do are the following.

From the Tools tab, activate the capture of the tags and use your site by visiting all the pages or making them visits from your users for a long time long period based on the use of your site (hours or days).
From the Tools tab perform the data clustering in the database (it can use many server resources).
Go to the Base rules tab and include in the CSP directives the desired values (help you with the table at the bottom of the page).
Go to to external scripts tab, inline scripts tab and scripts invoked by event handlers tab and authorize the execution of all the legitimate scripts present on the pages of your site.
Leaving the tag capture active, activate the policy test (at this stage the plugin will generate some violations of the temporary policy used to record additional values to be included in the directives of your “content security policy”).
After visiting again your site pages, disable the capture of the tags and repeat the previous steps 2, 3 and 4.
Enable site protection.

N.B. When you update plugins or themes, if something doesn’t work properly on your site pages, temporarily deactivate the protection and repeat steps 1 to 7.

Code and libraries

This version of the plugin uses:
\n* ivopetkov/HTML5DOMDocument to parse HTML;
\n* RubixML for machine learning from version 1.1.0 – PHP-ML was used in versions 1.0.x;
\n* opctim/php-nilsimsa to calculate and compare Nilsimsa digests.

The log functions have been taken from
\n* perfectyorg/perfecty-push-wp, something you should really try if you want to implement web Push notifications in your site.

The complete list of dependencies used in this plugin can be seen in dependency graph on GitHub.

Contributions, Issues, Bugs

Plugin code is hosted on a public repository on GitHub.
\nReach me over there to help and suggest.

\n","installation":"

Automatic installation

Plugin admin panel and add new option.
Search in the text box No unsafe-inline.
Position yourself on the description of this plugin and select install.
Activate the plugin from the WordPress admin panel.

Manual installation of ZIP file

Download the .ZIP file from this screen.
Select add plugin option from the admin panel.
Select upload option at the top and select the file you downloaded.
Confirm installation and activation of the plugin from the administration panel.

Manual FTP installation

Download the .ZIP file from this screen and unzip it.
FTP access to your folder on the web server.
Copy the whole no-unsafe-inline folder to the /wp-content/plugins/ directory
Activate the plugin from the WordPress admin panel.

\n","faq":"\n

\nIs this plugin easy to use?\n\n

This is not a click and go tool, but you can follow the instructions and implement a strict CSP.

\nHas this plugin been widely tested?\n\n

No.

\nWill this plugin impact site’s performance?\n\n

During capturing phase this plugin needs to write many data to database, so your site can slow down.
\nWhen the plugin enforces the CSP, it uses a mu-plugin to capture the output of the WordPress process, manipulate it and then send to browser.
\nI don’t have any measure of inherent overhead.

\nIs there another way to implement a strict content security policy in WordPress?\n\n

Not in my knowledge.

\nDo you offer professional support for this plugin?\n\n

No. But I do my best to offer free support on wordpress.org support forum in my spare time.

\nDo you offer professional support for CSP?\n\n

No.

\n\n","changelog":"

1.2.1

Bug fixes

1.2.0

Added persistence and online (partial) training to Knn classifiers
Added checks on startup for PHP build options
Fixed error thrown when malfromed URL are parsed while capture is enabled
Modified classificators tests
Improvements at the UI

1.1.5

Update external scripts table on plugin/theme/core update
Added a check for PHP extension requirements on startup
Added a polyfill to be used when PHP is built with –disable-mbregex

1.1.4

Fix src_attrib field size for long URLs
Remove spatie\\async from codebase and use fibers to execute long processes after page output
Fix summary report

1.1.3

Reduce the number of capture occurences
(dev) adding support for SCRIPT_DEBUG
Update composer and npm dependencies
Fix admin js for jquery deprecations
Adding some cookie scripts to the list of scripts that do not support SRI

1.1.2

Removed the use of ‘hash-value’ to allow external styles – not supported by CSP
Removed the use of ‘hash-value’ to allow external images – not supported by CSP
Added code to prune legacy external assets when pruning db
Forced synchronous code execution

1.1.1

Bug fixes
Improved compatibility with PHP 8.2

1.1.0

Moving to RubixML lib for machine-learning.
Fixed bug in capturing tags.
Fixed bug in pruning clusters.
Added a mutation observer for inline styles transfered to the internal css.

1.0.2

Fix results count error and default order in list_tables.
Avoid sending CSP on not HTML or XML Document responses.
Include page capture in asyncronous execution.
Removing double conversion of nilsimsa, while clustering.

1.0.1

Lowered priority for action and filter called on shutdown hook.
Moved default value for inline_scripts_mode option to ‘nonce’.
Fixed server error when csp header is too long.
Added setting to define HTTP Response Header Limit.
Added a waiting spinner on tools’ page of admin interface.

1.0.0

First plugin submission to WordPress.org

\n","screenshots":"

$\"Plugin's$
Plugin's tools tab in a multisite enviroment.
$\"External$
External scripts tab.
$\"Inline$
Inline scripts/styles tab.
$\"List$
List of CSP directives managed in Settings tab.
$\"A$
A database summary table at the bottom of tools tab.

"},"short_description":"No unsafe-inline helps you to build a Content Security Policy avoiding to use 'unsafe-inline' and 'unsafe-hashes'.","download_link":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.2.1.zip","screenshots":{"1":{"src":"https://ps.w.org/no-unsafe-inline/assets/screenshot-1.png?rev=2699768","caption":"Plugin's tools tab in a multisite enviroment."},"2":{"src":"https://ps.w.org/no-unsafe-inline/assets/screenshot-2.png?rev=2699768","caption":"External scripts tab."},"3":{"src":"https://ps.w.org/no-unsafe-inline/assets/screenshot-3.png?rev=2699768","caption":"Inline scripts/styles tab."},"4":{"src":"https://ps.w.org/no-unsafe-inline/assets/screenshot-4.png?rev=2699768","caption":"List of CSP directives managed in Settings tab."},"5":{"src":"https://ps.w.org/no-unsafe-inline/assets/screenshot-5.png?rev=2699768","caption":"A database summary table at the bottom of tools tab."}},"tags":{"content-security-policy":"content security policy","csp":"csp","multisite":"multisite","security":"security","unsafe-inline":"unsafe-inline"},"versions":{"1.0.0":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.0.0.zip","1.0.1":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.0.1.zip","1.0.2":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.0.2.zip","1.1.0":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.1.0.zip","1.1.1":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.1.1.zip","1.1.2":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.1.2.zip","1.1.3":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.1.3.zip","1.1.4":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.1.4.zip","1.1.5":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.1.5.zip","1.2.0":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.2.0.zip","1.2.1":"https://downloads.wordpress.org/plugin/no-unsafe-inline.1.2.1.zip","trunk":"https://downloads.wordpress.org/plugin/no-unsafe-inline.zip"},"donate_link":"https://paypal.me/GiuseppeF77","icons":{"1x":"https://ps.w.org/no-unsafe-inline/assets/icon-128x128.png?rev=2699768","2x":"https://ps.w.org/no-unsafe-inline/assets/icon-256x256.png?rev=2699768"}},{"name":"Subresource Integrity (SRI) Manager","slug":"wp-sri","version":"0.4.0","author":"Meitar","author_profile":"https://profiles.wordpress.org/meitar/","requires":"4.1","tested":"5.6.14","requires_php":false,"requires_plugins":[],"rating":58,"ratings":{"1":5,"2":1,"3":0,"4":0,"5":5},"num_ratings":11,"support_threads":0,"support_threads_resolved":0,"downloaded":14226,"last_updated":"2020-12-03 6:33pm GMT","added":"2015-06-05","homepage":"https://maymay.net/blog/projects/wp-sri/","sections":{"description":"

A WordPress plugin for easily adding a Subresource Integrity (SRI) declaration to any third-party content your pages load. The standards-based integrity attribute is a defense-in-depth best practice currently making its way into browsers. This plugin closely tracks the W3C draft.

Currently, the plugin automatically detects any third-party resources (like JavaScript libraries) and will make a SHA-256 hash of the content. It remembers this hash (until you uninstall the plugin or delete the hash from the admin interface), and modifies your page’s <script> and <link> elements on-the-fly. This way, your visitor’s Web browsers can automatically ensure that the specific library you’re using is the one they’re loading.

Using this plugin can dramatically reduce the liklihood that visitors to your site will be strong-armed into participating in an HTTP DDoS attack. For more information, see “An introduction to JavaScript-based DDoS” by Nick Sullivan.

Future versions of this plugin will also provide an easy-to-use interface for site administrators to maintain a customized list of resource hashes, and to trigger on-demand integrity checks of these resources.

This plugin is still somewhat skeletal. Feature requests and patches are welcome! Please provide a test case with your patch. See the tests subdirectory for unit tests.
\nIf you like this plugin, please consider making a donation for your use of the plugin, or better yet, contributing directly to my’s Cyberbusking fund. Your support is appreciated!

\n","installation":"

Upload the unzipped wp-sri folder to the /wp-content/plugins/ directory.
Activate the plugin through the ‘Plugins’ menu in WordPress.

\n","faq":"\n

\nWP-SRI breaks my plugin/theme. How can I prevent it from blocking my assets?\n

If you’re a site administrator, you can manually exclude specific resources by their URL from the Subresource Integrity Manager screen under Tools → Subresource Integrity Manager.

If you’re a plugin or theme author, you can use the option_wp_sri_excluded_hashes filter hook to dynamically whitelist assets. Please only do this for assets that are truly personalized, that is, only for assets whose URL is always the same but whose content is different for each user or page load.

For example, to ensure that the URL at https://example.com/personalized_content is never checked for integrity with SRI attributes, use the following PHP code:

function example_never_add_integrity_checking( $items ) {\n    $items[] = 'https://example.com/personalized_content';\n    return $items;\n}\nadd_action( 'option_wp_sri_excluded_hashes', 'example_never_add_integrity_checking' );\n

Learn more about this filter hook.

\n\n","changelog":"

Version 0.4.0

Stricter parsing for stylesheet tags; the filterTag function now requires a third parameter.

Version 0.3.0

Feature: Add ability to exclude URLs. Useful when SRI attributes block personalized assets.

Version 0.2.2

Bugfix: Load plugin textdomain files to prepare for translation.

Version 0.2.1

Add the crossorigin=\"anonymous\" attribute/value pair to modified elements to enable Firefox 43’s handling of integrity checks.

Version 0.2

Feature: A simple administrative interface can be found under the “Subresource Integrity Manager” option in your WordPress Tools menu. This interface allows you to view the URL and hash pairs currently known by your site, and to delete them. Deleting a known hash will cause WordPress to refetch and rehash the resource when it is next requested.

Version 0.1

Initial release.

\n"},"short_description":"Adds Subresource Integrity (SRI) attributes to your page's elements for better protection against JavaScript DDoS attacks.","download_link":"https://downloads.wordpress.org/plugin/wp-sri.zip","screenshots":[],"tags":{"mitigation":"mitigation","mitm":"mitm","security":"security","sri":"SRI","subresource-integrity":"subresource integrity"},"versions":[],"donate_link":"https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=TJLPJYXHSRBEE&lc=US&item_name=WordPress%20Subresource%20Integrity%20Plugin&item_number=wp-sri¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted","icons":{"default":"https://s.w.org/plugins/geopattern-icon/wp-sri.svg"}},{"name":"Pipfrosch jQuery","slug":"pipfrosch-jquery","version":"1.2.1","author":"Pipfrosch Press","author_profile":"https://profiles.wordpress.org/pipfroschpress/","requires":"4.1.0","tested":"5.4.16","requires_php":"7.0","requires_plugins":[],"rating":0,"ratings":{"1":0,"2":0,"3":0,"4":0,"5":0},"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"downloaded":717,"last_updated":"2020-06-16 2:43pm GMT","added":"2020-05-22","homepage":"https://wordpress.org/plugins/pipfrosch-jquery/","sections":{"description":"

The jQuery that current ships as part of WordPress is (as of WP 5.4.1) an older version of jQuery. As in ancient. This plugin allows you to instead use a much more modern version of jQuery, with optional compatibility for scripts that need the older jQuery calls.

This plugin also optionally allows you to securely select a public CDN for jQuery, including the appropriate Subresource Integrity (SRI) and CrossOrigin attributes. Using a CDN can speed up the loading of your website as there is a good chance a client visiting your website already has the identical file in their browser cache and does not need to fetch it again.

When a CDN is used, a small amount of code is added to your pages to provide a fallback where jQuery and the jQuery Migrate plugin are served from your site if either the CDN can not be reached by the client or if the SRI check fails.

The updated jQuery will not replace the core jQuery for administration pages. This is to avoid potential breakage of administrative pages.

The options for this plugin are managed from the WordPress ‘Dashboard’ in the ‘Settings’ area, using the ‘jQuery Options’ menu option within the ‘Settings’ area.

Plugin Options

There are four configurable options you can customize.

‘Use Migrate Plugin’ option

Enabled by default.

You may disable compatibility with scripts that require older versions of jQuery. This is not recommended.

The jQuery Migrate plugin provides compatibility with jQuery 1.9 through 3.0. It is enabled by default and provides compatibility with the version of jQuery that currently (WP 5.4.1) ships in WordPress, which is jQuery version 1.12.4.

Scripts written to use the version of jQuery that ships with WordPress may be registered with a dependency of jquery-core but use functions that are no longer supported in jQuery 3.5.1. When ‘Use Migrate Plugin’ is enabled, scripts that are registered with a dependency of jquery-core will trigger enqueuing of the Migrate plugin so that those scripts written for the older jQuery will still work. When ‘Use Migrate Plugin’ is disabled, then enqueuing of the Migrate plugin will only happen if scripts explicitly specify jquery-migrate or jquery as a dependency.

If some jQuery scripts break even with ‘Use Migrate Plugin’ enabled, they are likely written for jQuery prior to version 1.9. The only option in that case is to not use this plugin until you have upgraded that very old code.

It is highly recommended you update such old code as soon as possible, whether or not you plan to use this plugin.

Note

Please note that WordPress has provided jQuery for years, this results in many plugins and themes using jQuery out of convenience when they really did not need to.

Rumor is that a future release of WordPress may only use native JavaScript for everything JavaScript in WP Core. If hiring a JavaScript developer to update old jQuery code, make sure the JavaScript developer is wise enough to know when porting the code to native JavaScript makes more sense than continuing to use jQuery and when using jQuery really is the best approach. In other words, do not hire someone like me, I pretty much only use jQuery but that is admittedly not always the best approach, just the convenient approach.

‘Use Content Distribution Network’ option

Disabled by default.

By default, the updated jQuery scripts are served from within this WordPress plugin. This is because responsible plugin and theme developers do not (in my opinion) utilize third party resources by default.

I recommend you enable this option however doing so will result in front-end pages being served that reference a Third Party Resource. Links to those services and their privacy policies follows the section on Plugin Options.

‘Use Subresource Integrity’ option

Enabled by default.

This option only has meaning when the ‘Use Content Distribution Network’ option is enabled.

This option will add a Subresource Integrity hash that browsers can use to verify the resource retrieved is valid opposed to a modified possible trojan.

The only logical reason I can think of to disable this option is if you already have a different plugin that manages Subresource Integrity.

‘Select Public CDN Service’ option

Set to ‘jQuery.com CDN’ by default.

This option only has meaning when the ‘Use Content Distribution Network’ option is enabled.

This option lets you select which public CDN you wish to use from a list of five Public CDN services that are listed at https://jquery.com/download/#using-jquery-with-a-cdn

For many websites, the default ‘jQuery.com CDN’ is probably the best choice but it may not be the best choice for all websites, depending upon where the majority of your users are located geographically and which public CDN has a better response time in that geographical region.

External Third Party Services

When you enable the CDN option (recommended but disabled by default) a third party service will be used. You should make sure your website Privacy Policy makes users are aware of this. In the current version of WordPress (WP 5.4.1), the default Privacy Policy does make users aware that third party resources may be used, but you have to actually publish that policy and you should check it yourself in case it has been modified or in case the policy you have predates the current default policy and does not include a Third Party Resource notice.

This plugin always sets the crossorigin=\"anonymous\" attribute in association with the Third Party Service. This attribute instructs the browser not to send cookies or any other authentication information to the third party when retrieving the resource. Most modern browsers respect this attribute but some may not.

By default, the plugin will set the integrity=\"[[expected base64 encoded hash]]\" attribute in association with the Third Party Service. This instruct the browser not to use the downloaded resource if the hash does not match, protecting your users from possible trojans.

For SRI, this plugin uses the hashes associated with the files as provided by https://jquery.com/download/ with one exception (see the Hard-coded SRI Hashes section of this readme).

These are the potential third party services:

jQuery.com CDN

The default CDN used by this plugin when a CDN is enabled.

Link to service: https://code.jquery.com/

jQuery.com CDN is actually powered by StackPath.

Link to service: https://www.stackpath.com/
\nPrivacy Policy: https://www.stackpath.com/legal/privacy-statement/

CloudFlare CDNJS

When you have a CDN enabled and have selected the CloudFlare CDNJS option then
\nthe CloudFlare CDNJS service will be used.

Link to service: https://cdnjs.com/libraries/jquery/

For jQuery, CDNJS is powered by CloudFlare.

Link to service: https://www.cloudflare.com/
\nTerms of Use: https://www.cloudflare.com/website-terms/
\nPrivacy Policy: https://www.cloudflare.com/privacypolicy/

jsDelivr CDN

When you have a CDN enabled and have selected the jsDelivr option then the
\njsDelivr CDN will be used.

Link to service: https://www.jsdelivr.com/
\nPrivacy Policy: https://www.jsdelivr.com/privacy-policy-jsdelivr-net

Microsoft CDN

When you have a CDN enabled and have selected the Microsoft CDN option then the Microsoft CDN will be used.

Link to service: https://docs.microsoft.com/en-us/aspnet/ajax/cdn/overview
\nTerms of Use: https://docs.microsoft.com/en-us/legal/termsofuse
\nPrivacy Policy: https://privacy.microsoft.com/en-us/privacystatement

Google CDN

When you have a CDN enabled and have selected the Google CDN option then the Google CDN will be used.

Link to service: https://developers.google.com/speed/libraries
\nTerms of Use: https://developers.google.com/terms/site-terms
\nPrivacy Policy: https://policies.google.com/privacy

The Google CDN does not host the jQuery Migrate plugin. When you have a CDN enabled and the Migrate option enabled and have selected the Google CDN option then the jQuery.com CDN will be used for the jQuery Migrate plugin. The Privacy Policy for that CDN is listed earlier in this readme.txt file.

Hard-coded SRI Hashes

This plugin includes hard-coded Subresource Identity public hashes for the minified versions of the jQuery core library and the jQuery Migrate Plugin.

For a better understanding of what SRI is and why hard-coding the hashes is a necessary security feature, please see the file SubResourceIntegrity.md in this directory.

The hard-coded hashes can be verified against what is published at the https://code.jquery.com/ website.

Click on the minified link for the same version of jQuery (3.5.1) and a window will pop up with a script tag including the same SRI as what is defined by the PIPJQVSRI constant in versions.php.

Click on the minified link for the same version of jQuery Migrate (3.3.0) and a window will pop up with a script tag including the same SRI as what is defined by the PIPJQMIGRATESRI constant in versions.php.

CloudFlare CDNJS and jdDeliver CDN

The minified jQuery Migrate plugin hosted at CloudFlare CDNJS and jsDelivr CDN have the following addition at the end of the JS file that cause their hash to be different:

//# sourceMappingURL=jquery-migrate.min.map\n

For this reason, an SRI specific to them is used when CloudFlare CDNJS or jsDelivr CDN is the selected Public CDN.

This SRI value can be obtained from https://cdnjs.com/libraries/jquery-migrate

Mouse over the minified version and from the menu that appears select Copy SRI and the SRI that matches the file they serve will be copied to your clipboard and if the version is the same, it will match what is defined by the PIPJQMIGRATESRI_CDNJS constant in versions.php.

Public CDN Notes

As of May 28th, 2020 the following notes apply.

The Microsoft CDN does not yet have current versions of either the core jQuery library or the Migrate plugin. If you select that CDN, the files will be served from your host until the Microsoft CDN has them.

The Google CDN does not host any version of the jQuery Migrate plugin. If you select that option and have the Migrate plugin enabled, that plugin will be served from the jQuery.com CDN.

Plugin / Theme Compatibility

This plugin does not set the version for jQuery when registering the script. Unfortunately when registering a script with a version in WordPress, it always applies the query tag ?ver=whatever to the end of the resource and doing so with a CDN greatly reduces the odds that a browser will recognize it already has the scripts cached. Some plugins and themes may query for the version of jQuery being used. They should not do so, but some do. They will not get an answer if this plugin has run before they run and they will get the wrong answer if they run before this script has run.

jQuery scripts that depend upon certain versions should query for the capability within the JavaScript rather than depending upon a version specified to WordPress which may not always reflect what is actually served.

Update Policy

I will try to update this plugin when new versions of jQuery are released but it may not be as fast as some may like. You can bug me by leaving sending an e-mail to pipfroshpress[AT]gmail[DOT]com.

Please note updates to this plugin with new versions of jQuery will not be pushed until that majority of the supported CDNs have the file. New versions also will not be published if the accompanying Migrate plugin does not give support for scripts written for jQuery 1.12.4.

For the included jQuery Migrate plugin, I am less likely to notice when new versions are available but I do check whenever a new version of jQuery itself is released. Again you can bug me if needed.

Development takes place on github at https://github.com/pipfrosch/pipfrosch-jquery

The master branch will usually be exactly the same as what is distributed through WordPress except it will have a small README.md file. The branch pipjq is where I develop and what is in that branch may not always be stable. When a new release is ready and tested from the pipjq branch, it will be merged with master and then repacked for distribution through the WordPress SVN.

Please use the distribution from WordPress rather than from github unless you are testing. The version from WordPress is audited by more eyes than my github.

Versioning Scheme

Versions use the standard Major.Minor.Tweak scheme using integers for each. Code in my github may have a pre appended at the end to indicate is not a released version and should not be used on production systems.

Tweak bump

The Tweak is incremented by one when a minor change is made, such as adding a new language to the translation support. Generally you can ignore upgrading this plugin when there is just a Tweak bump.

Minor bump

The Minor is incremented by one when a functional bug is fixed or when an update to jQuery or the jQuery Migrate plugin is made that is not a substantial jQuery change. When Minor is bumped, Tweak will reset to 0. Generally you should upgrade when Minor is bumped.

Major bump

The Major will be incremented when there is an upgrade to jQuery that is significant in nature. Both Minor and Tweak are reset to 0 when Major
\nis bumped.

Generally you should test an update to Major before updating on a production system just in case some of your jQuery code needs tweaks before deployment.

Translations

This plugin is ready for translations but so far does not actually have any. Note that the only strings where translations are beneficial require administrative privileges to see (the Settings). Hopefully translations will soon be made for the benefit of WordPress administrators who have a preferred written language other than English.

Developers

If you have a plugin or theme that wants to know about versions, the following options are defined if this plugin is active:

pipjq_plugin_version defines the plugin version.
pipjq_jquery_version defines the jQuery version.
pipjq_jquery_migrate_version defines the jQuery Migrate plugin version

All three those of those options are defined as strings.

You can also get them directly from the defined constants PIPJQ_PLUGIN_VERSION, PIPJQV, and PIPJQMIGRATE respectively but I do not guarantee that I will continue to specify them with those constant into the long-term future. For example, if I switch to a more OOP approach they may be defined within a class rather than as constants. The options however will always be defined.

\n","faq":"

These are potential Frequently Asked Questions. No one has yet asked them. Actual frequently asked questions will be added if they come.

\n\n

\nWhy should I use this plugin over another plugin that does the same thing?\n

Only you can answer that question. The reason why I chose to write this plugin is that the other options I looked at either did not allow use of a CDN and/or did not provide Subresource Integrity when they did use a CDN and/or did not provide a fallback to serve jQuery and jQuery Migrate locally when a CDN failed to deliver the file or delivered a file that did not pass the SRI check.

If those issues do not concern you then maybe a different plugin addresses the issues that do concern you better than this one does.

For example, this plugin only provides for one version of jQuery and does not provide other jQuery plugins. If those are important to you then use a different plugin (or fork this one).

It is possible I may create additional WordPress plugins for the more commonly used jQuery plugins in the future as options but that has to be carefully done to make sure the $handle argument to wp_enqueue_script() matches what is expected by themes and plugins that want the jQuery plugin.

\nDoes the bundled version on jQuery impact blog administration?\n

No. It is possible that some versions of WordPress and probable that some plugins use jQuery for site administration that would break with the newer versions of jQuery. I recommend always using the version of jQuery that ships with WordPress for admin pages, so this plugin does not upgrade the WP Core jQuery for admin pages.

\nWhy does this plugin require PHP 7 or newer?\n

I have neither the financial means nor the will-power to set up a testing environment suitable for testing with versions of PHP that no one should still be using anyway.

PHP 7 also allows me to specify type hints for input parameters and function output, making it easier to port this plugin to php strict typing mode should WordPress ever move in that direction (as I hope it eventually does).

Please use at least PHP 7.2 if you can for reasons unrelated to this plugin.

\nWhy do I still sometimes see requests for jQuery in my server access log?\n

If you enabled a CDN but still see requests for jQuery in your server access logs, it means the client was not able to download jQuery from the CDN or that the file it downloaded did not pass security checks. When this happens, it triggers a fallback loading of jQuery from within the plugin directory.

\nCan I hire you to write me a plugin?\n

It does not hurt to ask but probably not, Pipfrosch Press is brand new and right now, coding for it is taking the majority of my time. When I code something for Pipfrosch Press I do not mind sharing I will share it, but projects outside of Pipfrosch Press are difficult for me to commit to.

\n\n","changelog":"

1.2.1 (Tuesday June 16, 2020)

Show version of jQuery UI in Setting page if Pipfrosch jQuery UI is installed.
Fixed some documentation typos.

1.2.0 (Monday May 25, 2020)

define versions as options, run upgrade check.
type hinting on function output
fixed bug with dependencies
No longer use activation hook (attempting to make more mu friendly but has not been mu tested)

1.1.0 (Friday May 22, 2020)

Added jQuery Migrate SRI hash for CDNJS and jsDelivr.

1.0.1 (Thursday May 21, 2020)

Updated readme.txt to include links to Public CDN services and their privacy policies.
Other cleanup of documentation.
No code changes from the 1.0.0 version.

1.0.0 (Wednesday May 20, 2020)

Initial release (jQuery 3.5.1 library with migrate 3.3.0).

\n","screenshots":"

$\"The$
The settings menu.
$\"Generated$
Generated WordPress HTML source code showing the failed CDN fallback code.

"},"short_description":"Use jQuery 3.5.1 and jQuery Migrate 3.3.0 with your WordPress powered website with a third party CDN if so desired.","download_link":"https://downloads.wordpress.org/plugin/pipfrosch-jquery.zip","screenshots":{"1":{"src":"https://ps.w.org/pipfrosch-jquery/assets/screenshot-1.png?rev=2310418","caption":"The settings menu."},"2":{"src":"https://ps.w.org/pipfrosch-jquery/assets/screenshot-2.png?rev=2310418","caption":"Generated WordPress HTML source code showing the failed CDN fallback code."}},"tags":{"jquery":"jquery"},"versions":{"1.1.0":"https://downloads.wordpress.org/plugin/pipfrosch-jquery.1.1.0.zip","1.2.0":"https://downloads.wordpress.org/plugin/pipfrosch-jquery.1.2.0.zip","1.2.1":"https://downloads.wordpress.org/plugin/pipfrosch-jquery.1.2.1.zip"},"donate_link":"https://pipfrosch.com/donate","icons":{"default":"https://s.w.org/plugins/geopattern-icon/pipfrosch-jquery.svg"}}]

subresource integrity

No unsafe-inline

Subresource Integrity (SRI) Manager

Pipfrosch jQuery

Get New Themes & Resources